Systems, methods, and computer products for processing payments using a proxy card

ABSTRACT

Systems, methods and computer program products for processing payments for a proxy card are provided. Embodiments of the system include a processor, and a memory in communication with the processor. The memory may be configured to store processing instructions for directing the processor to receive a request for authorization of a payment. In various embodiments, the request is triggered at a merchant server, by the use of a proxy card of the customer. The processor attempts to identify at least one desired payment mode for making the payment, from among payment mode(s) associated with the proxy card. The processor first selects the payment modes based at least in part on one or more selection criteria, such as predefined customer goals, and then the processor performs an authorization check to identify the desired payment modes. Subsequently, the processor authorizes the payment if at least one desired payment mode is identified.

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention generally relates to processing payments, and moreparticularly, to methods, systems, and computer program products forprocessing payments using proxy cards.

Related Art

Payment modes, such as credit cards, debit cards, bank accounts,pre-paid gift cards, health savings accounts, loyalty rewards accounts,redemption coupons, and the like are used for conducting transactions.Consumers often carry two or more cards or a combination of cards and apayment device such as a fob.

For a variety of reasons, different cards may be used depending on thetype of transaction. For example, a merchant may not accept a particularpayment mode. Or, the consumer may wish to use various payment modes totake advantage of the unique benefits associated with each. A loyaltygas card may offer a good deal or generous points for gas purchases. Aflight card may provide benefits in the form of accumulating air miles.As a result, a consumer may carry one or more credit cards for commonuse and one or more store-specific or brand-specific transaction cardsfor use in specific transactions where they provide more attractiveoffers/discounts.

Managing, as well as simply carrying, a large number of payment modescan be cumbersome. Discounts and offers and their associated severalpayment modes need to be tracked and several receipts may need to besigned.

Moreover, the more payment modes a consumer carries, the higher the riskof losing one of them. A lost card or fob might not be detectedimmediately, giving time to someone else to misuse the card before it isreported missing.

On the other hand, a consumer who conserves wallet space by carryingfewer payment modes often finds that on various occasions the mostdesirable payment mode for effecting a particular transaction is notavailable when needed. In addition, it may be the case that a merchantdoes not accept the payment mode most commonly used by the consumer.

It would be useful to process transactions using a single card, deviceor a single account number which enables the use of one or more paymentmodes available to the consumer, with no changes required in theexisting point of sale (POS) infrastructure.

SUMMARY OF THE INVENTION

The present invention meets the above-mentioned needs by providingmethods, systems and computer program products for processing paymentsfor a proxy card of a customer.

According to one embodiment of the present invention, there is discloseda method for processing a payment for a proxy card. The method includesreceiving a request for authorization of the payment at a server. Invarious embodiments, the authorization request is triggered at amerchant server by the use of a proxy card of the customer. The methodinvolves attempting to identify a desired payment mode for making thepayment, from among one or more payment modes associated with the proxycard, in response to the authorization request received from themerchant server. The payment modes are first selected based at least inpart on one or more selection criteria and then an authorization checkis performed to identify the desired payment mode. Subsequently, thepayment is authorized if at least one desired payment mode issuccessfully identified.

According to yet a further embodiment of the present invention, there isdisclosed a system for processing a payment for a proxy card. Variousembodiments of the system include at least one processor, and a memoryin communication with the at least one processor. The memory may beconfigured to store a plurality of processing instructions for directingthe at least one processor to receive a request for authorization of thepayment. In various embodiments, the authorization request is triggeredat a merchant server by the use of a proxy card of the customer. Theprocessor further attempts to identify at least one desired payment modefor making the payment, from among one or more payment modes associatedwith the proxy card of the customer. The processor first selects thepayment modes based at least in part on one or more selection criteriaand then the processor performs an authorization check to identify thedesired payment modes. Subsequently, the processor authorizes thepayment if at least one desired payment mode is identified.

According to another embodiment of the present invention there isprovided a computer program product for processing a payment for a proxycard. The computer program product includes a computer usable mediumhaving control logic stored therein for causing a computer to processthe payment for the proxy card. The control logic includes a first,second, third, fourth and a fifth computer readable program code. Thefirst computer readable program code causes the computer to receive arequest for authorization of a payment. In various embodiments, theauthorization request is triggered at a merchant server by the use of aproxy card of the customer. The second computer readable program codecauses the computer to attempt to identify at least one desired paymentmode options for making the payment, from among one or more paymentmodes associated with the proxy card. The computer readable program codefirst selects the payment modes based at least in part on one or moreselection criteria and then performs an authorization check to identifythe desired payment modes. The third computer readable program codecauses the computer to authorize the payment if at least one desiredpayment mode is identified.

Various embodiments of the present invention provide systems, methods,and computer program products for processing a payment for a proxy card.The various embodiments may also include performing one or more of theaforementioned functions independently and in any order, as per theneed.

Further features and advantages of the present invention as well as thestructure and operation of various embodiments of the present inventionare described in detail below with reference to the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will become moreapparent from the detailed description set forth below when taken inconjunction with the following drawings.

FIG. 1 depicts a payment processing network for processing paymentsusing proxy cards in accordance with an embodiment of the presentinvention;

FIG. 2 is a schematic system diagram of an exemplary system used toimplement or practice one or more embodiments of the present invention;

FIG. 3 is a flowchart illustrating one example process for processingpayments using proxy cards, according to one embodiment of the presentinvention;

FIG. 4 shows a table representing various pre-defined preferences,according to an exemplary embodiment of the present invention;

FIG. 5 shows a table representing one or more payment mode options,according to an exemplary embodiment of the present invention;

FIGS. 6A and 6B show a flowchart illustrating one example process forprocessing payments using proxy cards, according to another embodimentof the present invention; and

FIG. 7 is a block diagram of one example computer system useful forimplementing the present invention, according to one embodiment of thepresent invention.

DETAILED DESCRIPTION OF THE INVENTION I. Overview

The present invention is now described in more detail herein in terms ofan exemplary financial transaction network. This is for convenience onlyand is not intended to limit the application of the present invention.In fact, after reading the following description, it will be apparent toone skilled in the relevant art(s) how to implement the followinginvention in alternative embodiments (e.g., flexible spending accountprocessing networks such as health savings account networks, loyaltyreward networks, electronic coupon processing networks, and the like.).

The terms “user,” “end user,” “consumer,” “customer,” “participant,”and/or the plural form of these terms are used interchangeablythroughout herein to refer to those persons or entities capable ofaccessing, using, being affected by and/or benefiting from the exampleembodiments described herein.

The terms “business” or “merchant” may be used interchangeably with eachother and shall mean any person, entity, distributor system, softwareand/or hardware that is a provider, broker and/or any other entity inthe distribution chain of goods or services. For example, a merchant maybe a grocery store, a retail store, a travel agency, a service provider,an on-line merchant or the like.

“Financial transaction” means an event between a buyer and a seller,where the buyer acquires an asset, which could be a physical asset or anelectronic asset, from the seller in exchange for payment.

The terms “transaction” and “purchases” may be used interchangeably andshall refer to any financial transaction initiated by the customer at apoint of purchase, which could be a physical POS terminal or anon-physical POS terminal such as an Internet webpage.

A “transaction account” as used herein refers to an account associatedwith an open account or a closed account system (as described below).The transaction account may exist in a physical or non-physicalembodiment. For example, a transaction account may be distributed innon-physical embodiments such as an account number, frequent-flyeraccount, telephone calling account or the like. Furthermore, a physicalembodiment of a transaction account may be distributed as a financialinstrument.

A “financial transaction” instrument may be traditional plastictransaction cards, titanium-containing, or other metal-containing,transaction cards, clear and/or translucent transaction cards, foldableor otherwise unconventionally-sized transaction cards, radio-frequencyenabled transaction cards, or other types of transaction cards, such ascredit, charge, debit, pre-paid or stored-value cards, or any other likefinancial transaction instrument. A financial transaction instrument mayalso have electronic functionality provided by a network of electroniccircuitry that is printed or otherwise incorporated onto or within thetransaction instrument (and typically referred to as a “smart card”), ormay be a fob having a transponder and an RFID reader. For example, afinancial transaction instrument could take the form of a wristwatch, awristband, or the like.

“Open cards” are financial transaction cards that are generally acceptedat different merchants. Examples of open cards include the AmericanExpress®, Visa®, MasterCard® and Discover cards, which may be used atmany different retailers and other businesses. In contrast, “closedcards” are financial transaction cards that may be restricted to use ina particular store, a particular chain of stores or a collection ofaffiliated stores. One example of a closed card is a pre-paid gift cardthat may only be purchased at, and only be accepted at, a clothingretailer, such as The Gap® store.

“Stored value cards” are forms of transaction instruments associatedwith transaction accounts, wherein the stored value cards provide cashequivalent value that may be used within an existing payment/transactioninfrastructure. Stored value cards are frequently referred to as gift,pre-paid or cash cards, in that money is deposited in the accountassociated with the card before use of the card is allowed. For example,if a customer deposits ten dollars of value into the account associatedwith the stored value card, the card may only be used for payments up toten dollars.

With regard to use of a transaction account, users may communicate withmerchants in person (e.g., at the box office), telephonically, orelectronically (e.g., from a user computer via the Internet). During theinteraction, the merchant may offer goods and/or services to the user.The merchant may also offer the user the option of paying for the goodsand/or services using any number of available transaction accounts.Furthermore, the transaction accounts may be used by the merchant as aform of identification of the user. The merchant may have a computingunit implemented in the form of a computer-server, although otherimplementations are possible.

In general, transaction accounts may be used for transactions betweenthe user and merchant through any suitable communication device, suchas, for example, a telephone network, intranet, the global, publicInternet, a point of interaction device (e.g., a point of sale (POS)device, personal digital assistant (PDA), mobile telephone, kiosk,etc.), online communications, off-line communications, wirelesscommunications, and/or the like.

An “account,” “account number” or “account code”, as used herein, mayinclude any device, code, number, letter, symbol, digital certificate,smart chip, digital signal, analog signal, biometric or otheridentifier/indicia suitably configured to allow a consumer to access,interact with or communicate with a financial transaction system. Theaccount number may optionally be located on or associated with anyfinancial transaction instrument (e.g., a rewards, charge, credit,debit, pre-paid, telephone, embossed, smart, magnetic stripe, bar code,transponder or radio frequency card).

The account number may be distributed and stored in any form of plastic,electronic, magnetic, radio frequency (RF), wireless, audio and/oroptical device capable of transmitting or downloading data from itselfto a second device. A customer account number may be, for example, asixteen-digit credit card number. Each credit card issuer has its ownnumbering system, such as the fifteen-digit numbering system used byAmerican Express Company of New York, N.Y. Each issuer's credit cardnumbers comply with that company's standardized format such that anissuer using a sixteen-digit format will generally use four spaced setsof numbers in the form of:

N1N2N3N4N5N6N7N8N9N10N11N12N13N14N15N16

The first five to seven digits are reserved for processing purposes andidentify the issuing institution, card type, etc. In this example, thelast (sixteenth) digit is typically used as a sum check for thesixteen-digit number. The intermediary eight-to-ten digits are used touniquely identify the customer, card holder or cardmember.

A merchant account number may be, for example, any number oralpha-numeric characters that identifies a particular merchant forpurposes of card acceptance, account reconciliation, reporting and thelike.

It should be noted that the transfer of information in accordance withthe present invention, may be done in a format recognizable by amerchant system or account issuer. In that regard, by way of example,the information may be transmitted from an RFID device to an RFIDreader, or from the RFID reader to the merchant system in magneticstripe or multi-track magnetic stripe format.

Because of the proliferation of devices using magnetic stripe format,the standards for coding information in magnetic stripe format werestandardized by the International Organization for Standardization inISO/IEC 7811-n (characteristics for identification cards) which areincorporated herein by reference. The ISO/IEC 7811 standards specify theconditions for conformance, physical characteristics for the card(warpage and surface distortions) and the magnetic stripe area(location, height and surface profile, roughness, adhesion, wear andresistance to chemicals), the signal amplitude performancecharacteristics of the magnetic stripe, the encoding specificationincluding technique (MFM), angle of recording, bit density, fluxtransition spacing variation and signal amplitude, the data structureincluding track format, use of error correction techniques, user datacapacity for ID-1, ID-2 and ID-3 size cards, and decoding techniques,and the location of encoded tracks.

Typically, magnetic stripe information is formatted in three tracks.Certain industry information must be maintained on certain portion ofthe tracks, while other portions of the tracks may have open datafields. The contents of each track and the formatting of the informationprovided to each track is controlled by the ISO/IEC 7811 standard. Forexample, the information must typically be encoded in binary. Track 1 isusually encoded with user information (i.e. name) in alphanumericformat. Track 2 is typically comprised of discretionary andnondiscretionary data fields. In one example, the nondiscretionary fieldmay comprise 19 characters and the discretionary field may comprise 13characters. Track 3 is typically reserved for financial transactions andincludes enciphered versions of the user's personal identificationnumber, country code, current units amount authorized per cycle,subsidiary accounts, and restrictions.

As such, where information is provided in accordance with the presentinvention, it may be provided in magnetic stripe format. For example,the counter values, authentication tags and encrypted identifiers,described herein, may be forwarded encoded in all or a portion of a datastream representing data encoded in, for example, track 2 or track 3format.

“Proxy instrument” or “proxy card” may be used interchangeably with eachother and shall mean a financial transaction instrument that can be usedto represent multiple payment modes. For example, a proxy instrument canbe a typical transaction card such as a credit card, debit card,stored-value card and the like, which when used to make a transaction(e.g., a purchase), triggers a procedure which processes the paymentusing one of several accounts. Such a card can also be used to cause acombination of available transaction accounts to be displayed on a userinterface, such as a mobile presentation device or on a POS. Such arepresentation is often referred to as a “virtual wallet.” The virtualwallet receives, from a server, data indicating the availabletransaction accounts and payment options linked to the proxy card. Inturn, the customer can access the virtual wallet and choose one or morepayment options based on individual preference.

In another embodiment, a customer who is not in physical possession of aproxy card enters a number or alpha-numeric code associated with theproxy card into the POS. The POS then displays the account and paymentchoices to the customer, from which the customer can choose to completea transaction. In this way, the customer need not have the physicalproxy card in their possession to complete the transaction.

A “proxy account” is an account that can be used to represent ofmultiple actual accounts.

An “out-of-band communication” is any form of communication that is notwith a point of sale interaction. An out-of-band communication may be inthe form of a telephone or network communication to the card issuer orprocessor. Examples of out-of-band notification include, but may not belimited to notification through an SMS message, a voice call back, or anemail.

As will be explained in more detail below, users can store predefinedpreferences as to which payment mode(s) to use to pay for a transaction.For example, a customer may set preferences to split the amount of atransaction between multiple payment modes. The customer may choose topay part of the transaction amount using a pre-paid gift card and paythe rest of the amount through a credit card.

A proxy-card payment gateway uses an out-of-band communication toreceive customer authentication information and a selection as to whichpayment mode(s) to use to make the payment. Additional authenticationlevels may be required based on individual preferences. For instance, toauthenticate a payment request, a customer may contact an automated callcenter and enter a Card Identification Number (CID), such as PersonalIdentification Number (PIN) for a debit card, or enter a preregisteredbank account number if the customer chooses to pay through a bankaccount.

Because multiple payment modes may be used, multiple authentications maybe required at different stages of the transaction or based on thesecurity requirements associated with each transaction account.Alternatively, one authentication may be used to cause other prestoredauthentication passwords to be transmitted to their respective paymentprocessing systems.

II. System

FIG. 1 depicts a payment processing network 100 for processing paymentsusing proxy cards in accordance with an embodiment of the presentinvention. Payment processing network 100 includes a communicationsnetwork 110 that connects sellers, buyers, processors and/or acquiringbanks that process and settle transactions. Communication network 110may be a wide area network (WAN), a local area network (LAN), anEthernet, Internet, an Intranet, a cellular network, a satellitenetwork, a near field communication (NFC) network, a BLUETOOTH network,a WI-FI network, or any other suitable network for transmitting data. Invarious embodiments, communication network 110 may include a combinationof two or more of the aforementioned networks and/or other types ofwired and/or wireless networks known in the art.

Payment processing network 100 includes a proxy-card payment gateway 102that serves to provide a network in which information is transferredamong merchants, customers and financial networks, such as paymentprocessors or acquiring banks, to process authorizations and payments inconnection with transactions.

A proxy number or account identifier acts as a trigger to open a virtualpayment wallet stored at the proxy-card payment gateway 102.

A merchant server 104, also sometimes known as a “commerce server,” is aserver on the communications network 110 constructed to handletransactions such as online purchases and credit card transactions.Merchant server 104 may also provide an online storefront and shoppingcart infrastructure.

A customer payment preferences store 106 stores pre-defined customerpreferences as to which payment mode(s) to use for a transaction. One ormore payment gateways such as a first payment gateway 108 a, a secondpayment gateway 108 b, a third payment gateway 108 c, a point of sale(POS) 112, a payment preference management server 114, and a customerpayment preferences store 106, communicate through communication network110. POS 112 refers to a terminal or, more generally, to the hardwareand software for reading financial transaction instruments used forpayment of purchased goods and/or services.

A customer initiates a transaction through POS 112 at a merchantlocation, and generates an authorization request. For example, atransaction can be initiated by swiping a financial transactional cardof the customer at the POS 112. POS 112, in turn, generates theauthorization request and transmits it over a network to the proxy-cardpayment gateway 102 via the merchant server 104.

Proxy-card payment gateway 102 determines whether the authorizationrequest is associated with a proxy-card. If so, the proxy-card paymentgateway 102 opens a virtual payment wallet associated with theproxy-card and determines the available payment mode options associatedwith the corresponding proxy account.

Payment preference management server 114 receives input from thecustomer and stores the customer's preferences in a memory or likestorage device. In one example aspect, the preferences identify whichpayment mode option(s) to use, based in part, on the nature of theauthorization request. The term “preferences” refers to any rules and/orsettings associated with the payment modes, and configured by thecustomer. In an example embodiment, the payment preference managementserver 114 is a Web server which allows dynamic configuration of thepreferences by the customer. The payment preference management server114 also can communicate preferences to the customer payment preferencesstore 106, which is in communication with the proxy-card payment gateway102 via a communication network 110. The customer may use variousexisting interaction channels such as the Internet, mobile, etc., toaccess the payment preference management server 114.

FIG. 2 is a schematic system diagram of an exemplary system 200 used toimplement or practice one or more embodiments of the present invention.As shown in the FIG. 2, the customer may swipe a financial transactioncard at the POS 112 to initiate a transaction. Subsequently, POS 112triggers the merchant server 104 via the communication network 110 tosend an authorization request to the proxy-card payment gateway 102. Theproxy-card payment gateway 102 determines whether the authorizationrequest is received from the proxy card of the customer. Since, therequest is received from the proxy card, the proxy-card payment gateway102 opens a virtual payment wallet stored at the proxy-card paymentgateway 102. The virtual payment wallet stores information related toone or more payment modes such as, but not limited to, a debit cardaccount, credit card account, bank account, pre-paid gift card, freesavings account, flexible spending account, health savings account,reward points, redemption coupons, and the like, etc., in a secureenvironment.

Subsequently, the proxy-card payment gateway 102 attempts to identify atleast one desired payment mode to use to make the payment from among thepayment modes associated with the proxy card of the customer. Thisdecision is based on one or more preferred selection criteria. Theselection criteria may include, but are not limited to, selecting apayment mode based on the pre-defined preferences of customer and/orcommunicating one or more payment mode options to the customer in orderto receive a selected payment mode as per the customer preference. Forexample, the proxy-card payment gateway 102 queries the customer paymentpreferences store 106 to identify if the customer has configured anypre-defined preferences. For instance, the customer can add apre-defined preference to the customer payment preferences store 106defining a desired goal the customer wishes to attain. The goal mayinclude, for example, a number of desired reward points, a total amountof transactions per month required to receive a discount, etc. Inanother embodiment, if no pre-defined customer preferences areassociated with the authorization request, then the proxy-card paymentgateway 102 may communicate payment mode options to the customer andrequest the customer to select a payment mode from the option. Theproxy-card payment gateway 102 may communicate the payment mode optionsto the customer by sending an out-of-band notification to the customer.As described above, an out-of-band notification can be any notificationwhich is transmitted through a communication channel other than thenormal channel associated with an authorized request. In the exampleimplementation shown in FIG. 2, the out-of-band notification is sent toa mobile phone 116 of the customer.

In addition to communicating the payment mode options to the customer,the proxy-card payment gateway 102 may further recommend a preferredpayment mode to the customer based on, for example, past behavior of thecustomer and/or a majority of other customers that initiate similarauthorization requests. Past behavior may include transactions made bythe customer or other customers by one or more payment modes in thepast, and recorded in the one or more databases (not shown) of theproxy-card payment gateway 102. However, in an embodiment of the presentinvention, the customer may not prefer that the selected payment mode berecorded as an indication of the past behavior. In addition tosuggesting payment options to the customers, the proxy-card paymentgateway 102 may also offer the customer an option to pre-define thesuggested payment modes for all future transactions similar to thecurrent authorization request.

In another embodiment, the proxy-card payment gateway 102 recommends apayment mode to a first customer by performing collaborative filteringof payment preferences stored in the customer payment preferences store106. In particular, the proxy-card payment gateway 102 filters paymentpreferences within the customer payment preferences store 106 toidentify similar customers, that is, customers having defined paymentpreferences similar to payment preferences defined by the firstcustomer. The proxy-card payment gateway 102 then recommends a paymentmode to the first customer according to payment preferences defined bythe similar customers. In this way, the first customer can benefit froman ongoing promotion associated with a particular payment mode, withoutthe need to maintain continuous awareness of the ongoing promotion.Rather, the first customer can take advantage of the ongoing promotionby relying on the payment preferences of similar customers.

The proxy-card payment gateway 102 also may be in communication with oneor more external servers or databases (not shown) that gather or providedynamically updated information on the available payment mode options.For example, information on a payment mode option may include changes inthe credit limit of a payment mode (e.g. credit card), new offers,product specific discounts provided that a particular payment mode beused, and the like. This information may be subsequently transmitted forprocessing and analysis to the proxy-card payment gateway 102 over thecommunication network 110, and may be transmitted in an encrypted orotherwise secure format, in a wide variety of known manners. Thesesuggestions are communicated to the customer by proxy-card paymentgateway 102 when, for example, dynamic updates are received for the oneor more payment mode options.

Referring again to the example scenario of FIG. 1, once the proxy-cardpayment gateway 102 selects at least one payment mode, it transmitscorresponding authorization requests to their respective paymentgateways 108 a-c. In turn, the payment gateways 108 a-c, which haveissued the selected payment modes, perform their respectiveauthorization checks.

In an embodiment of the present invention, the proxy-card paymentgateway 102 may be operated by a proxy card provider, which has issuedone or more of the selected payment modes. Thus, the proxy-card paymentgateway 102 and/or other payment gateways 108 a-c may performcorresponding authorization checks on the selected cards.

The authorization process can be used to identify at least one desiredpayment mode for making the payment based at least in part on one ormore authorization criteria, which may include, but not limited to,checking available credit limit of the payment mode for making thepayment, expiry date of the payment mode, validity of the payment mode,other customer preferences associated with the payment mode and so on.If the selected payment mode is authorized, then the proxy-card paymentgateway 102 authorizes the payment from the selected payment mode.However, if the selected payment modes is not authorized, then theproxy-card payment gateway 102 may select at least one alternativepayment mode. The proxy-card payment gateway 102 selects the alternativepayment modes based on the selection criteria, which may includechecking if pre-defined preferences define a re-selection criteria,communicating the rest of the payment mode options to the customer, orby checking a past behavior of the customer or other customers forsimilar authorization requests. A detailed explanation of an exemplaryre-selection criteria is discussed below with reference to FIG. 4.

In one embodiment, a payment mode for a financial transaction is changedafter the transaction has been authorized. A customer initiallyauthorizes a transaction using a first payment mode, but then decides touse a second payment mode to obtain preferred advantages, such as rewardpoints. The customer transmits an out-of-band communication to theproxy-card payment gateway 102 to select the second payment mode to beused for the transaction instead of the first payment mode.Alternatively, the second payment mode can be suggested by the paymentpreference management server 114 instead of being requested by thecustomer. In this case, an out-of-band communication suggesting thesecond payment mode is transmitted from the proxy-card payment gateway102 to the customer.

Once the desired payment mode is identified, the proxy-card paymentgateway 102 sends on or more authorization requests to the respectivepayment gateways 108 a-c to authorize the payment. The proxy-cardprovider that operates the proxy card payment gateway 102 may itselfhave issued one or more desired payment modes and subsequently,authorizes the payment from the desired payment mode. On successfulcompletion of the payment, the proxy-card payment gateway 102 transmitsan authorization code to the POS 112 via the merchant server 104. ThePOS 112 subsequently receives the authorization code and a cashierprovides a hard copy and/or a soft copy of the receipt, including theauthorization code, to the customer if necessary. In an embodiment ofthe present invention, the customer may be required to sign the receiptif, for example, the proxy card is issued as a credit card, or provide a“personal identification number” (PIN) if, for example, the proxy cardis issued as a debit card. In another embodiment, the customer adds ane-mail address to the customer payment preferences store 106, and theproxy-card payment gateway 102 transmits an electronic receipt to thee-mail address.

The proxy-card payment gateway 102 records the transactions carried outby the customer in one or more databases (not shown) that allow thecustomer to set preferences facilitating real time “tagging” oftransactions. The customer may tag a transaction by, for example,storing in the database contextual information associated with thetransaction, such as a location (e.g., a Geocode™, or GPS information)of the point of the transaction, or a voice message associated with thetransaction. The voice message may indicate, for example, that the itemassociated with the transaction would make a great gift for the birthdayof a friend. In one embodiment the tagging information is stored on thedevice and is correlated with the proxy card payment gateway 102databases at a later time. When the customer sets these preferences theyare provided with the option of later pulling up any transaction datausing the tags associated with the transactions. For example, if thecustomer wishes to review a history of all food related transactionsmade in the recent past, the customer may use a menu option on a mobilephone to send a simple command such as “HIST-FOOD 30” through SMS/voicemessage to receive the transaction data for all food related purchasesin the last 30 days. The customer may either use the out-of-bandcommunication or the existing communication network 110 to send theappropriate commands for receiving transaction data through theproxy-card payment gateway 102.

III. Process

FIG. 3 is a flowchart illustrating an example process 300 for processingpayments using proxy cards, according to an embodiment of the presentinvention. Preferably, the process 300 may be executed in theenvironment 100 shown in FIG. 1.

The process 300 begins at step S302, at which the proxy-card paymentgateway 102 receives a request for authorization of a payment. In anexample embodiment of the present invention, the request forauthorization is triggered by swiping of the proxy card of the customerat the POS 112. In an alternate example embodiment, the proxy card maybe a radio frequency enabled transaction card, which may be wirelesslydetected by a card reader, at the POS 112. In a further exampleembodiment, the request for authorization may be triggered by enteringvia a Web interface proxy card details, such as a card identificationnumber (CID). The Web interface may be hosted by an online websitecapable of making online transactions.

At step S304, the proxy-card payment gateway 102 attempts to identify atleast one desired payment mode for making the payment, from among one ormore payment modes associated with the proxy card. As explained above,examples of payment mode options include, but are not limited to, adebit card, a credit card, a bank account, a free savings account, aflexible spending account, a health savings account, a pre-paid giftcard, a loyalty card, stored-value card, redemption coupons, and thelike. The proxy-card payment gateway 102 initially selects at least onepayment mode based on one or more selection criteria. For example, in anembodiment of the present invention, the proxy-card payment gateway 102looks up customer payment preferences store 106 to determine if thecustomer has configured one or more pre-defined preferences associatedwith the request for authorization of the payment. A detailedexplanation of the pre-defined preferences is described with referenceto the FIG. 4.

If no pre-defined customer preferences are associated, then theproxy-card payment gateway 102 communicates the one or more payment modeoptions to the customer. The customer then selects a preferred paymentmode. The proxy-card payment gateway 102 may communicate the paymentmodes to the customer by sending an out-of-band notification to thecustomer. In an exemplary case, the out-of-band notification is sent tothe mobile phone 116 of the customer. Examples of out-of-bandnotification include, but are not limited to, notification through anSMS message, a voice call back, an email and the like.

The proxy-card payment gateway 102 may also communicate alternativepayment modes to the customer even if the pre-defined preferences areassociated with a request for authorization of a payment. For example,the customer may prefer the proxy-card payment gateway 102 tocommunicate the selected payment modes to the customer for purchasesabove a threshold amount, even if the pre-defined preferences areassociated for the authorization request.

The proxy-card payment gateway 102 may also suggest a preferred paymentmode to the customer, based on past behavior of other customers thathave made similar authorization requests for payment.

Subsequently, the proxy-card payment gateway 102 sends authorizationrequests to the respective payment gateways 108 a-c, which have issuedthe selected payment modes, to perform authorization check(s). In anembodiment of the present invention, the proxy-card provider associatedwith proxy-cart payment gateway 102 may itself have issued one or moreselected payment modes. The proxy-card payment gateway 102 and otherpayment gateways 108 a-c perform their respective authorization checkson the selected cards issued by them. The authorization check isperformed to identify at least one desired payment mode for making thepayment. Further, the authorization check is based at least in part onone or more authorization criteria, which may include checking anavailable credit limit of the payment mode for making the payment, anexpiry date of the payment mode, validity of the payment mode, customerpreferences associated with a particular payment mode, and the like.

If the selected payment mode is authorized, then the proxy-card paymentgateway 102 sends request to the respective payment gateways 108 a-c,which correspond to the selected payment modes, to authorize thepayment. As described above, the proxy-card payment gateway 102 may beassociated with a proxy-card provider which has issued one or moreselected payment modes. At step S306, the proxy-card payment gateway 102and other payment gateways 108 a-c authorize the payment from theselected payment modes. On completion of the payment, the proxy-cardpayment gateway 102 sends an authorization code back to the POS 112 viathe merchant server 104. Preferably proxy-card payment gateway 102 sendsa single authorization code back to POS 112.

If the selected payment modes are not authorized, then the proxy-cardpayment gateway 102 may select at least one alternative payment mode,based on one or more selection criteria. The one or more selectioncriteria, may include checking whether pre-defined preferences arepresent for the re-selection criteria, communicating the rest of thepayment mode options to the customer for selecting the payment modebased on the customer preference, or by checking a past behavior of thecustomer or other customers for similar authorization requests, etc.

FIG. 4 shows a table representing various pre-defined preferences, inaccordance with an exemplary embodiment of the present invention. Basedon individual requirements, customers may pre-define preferencesassociated with the request for authorization of payment. Table 402represents exemplary pre-defined preferences. As shown in the table 402,the customer may pre-define a loyalty gas card to be used for makingpayments related to gas related transactions. Similarly, loyalty foodcards may be used for making payment at restaurants. The customer mayalso pre-define a particular payment mode option for transactionsbetween pre-defined amounts. For example, as shown in table 402, thecustomer may predefine to choose redemption coupons for transactions ina range of $10-$500. Similarly, the customer may predefine to split thetransaction amount between two payment modes, for example betweenpayment modes “A” and “B”, for transactions worth greater than $5000. Inanother example implementation, the customer may pre-define to usepre-paid gift card as default payment mode for all transactions untilthe amount available in the pre-paid card gets exhausted.

The customer may also configure pre-defined preferences for re-selectionof payment modes when previously selected payment modes are notaccepted. For example, if the selected payment modes fail anauthorization check performed by the proxy-card payment gateway 102 are-selection procedure is performed in accordance with the variouspre-defined preferences for re-selection of payment modes shown in table402. For example, if the loyalty gas card fails an authorization check,then according to the re-selection preferences of the customer, theproxy-card payment gateway 102 communicates the available payment modeoptions to the customer. In another example, for transactions in a rangeof $10-$500, if the redemption coupons are exhausted, then according tothe re-selection preferences, the proxy-card payment gateway 102 selectspayment mode “A” for making the payment. Similarly, for re-selection incase of transactions worth above $5000, the proxy-card payment gateway102 may select payment mode “C”, according to the re-selectionpreferences associated by the customer. In a further example, if thepre-paid gifts card amount is exhausted, then the proxy-card paymentgateway may select payment mode “D”, according to the re-selectionpreferences associated by the customer. Of course, FIG. 4 represents oneexample and is not meant to be limiting. The table presented is merelyfor example. Further, the pre-defined preferences can be based on one ormore different needs of the customers.

FIG. 5 shows a table representing one or more payment mode options, inaccordance with an exemplary embodiment of the invention. The proxy-cardpayment gateway 102 may communicate the one or more payment mode optionsto the customer and request the customer to select a preferred paymentmode by sending an out-of-band notification. Examples of out-of-bandnotification include notification through an SMS message, a voice callback, an email and the like. The proxy-card payment gateway 102 can alsocommunicate the offers to the customer based on a preferred paymentmode. The preferred payment mode, in turn, is based on dynamic updatesreceived from one or more of the payment mode providers. Table 502represents payment mode options available to the customer and exemplarydynamic updates associated with those payment modes. For example, onepayment mode option is a payment mode “A”. The proxy-card paymentgateway 102 communicates the dynamic update associated with the paymentmode “A”. For example, on using payment mode “A”, the customer getsdouble rewards points for each transaction of $100. Similarly, usingpayment mode “B” provides the user with discount coupons worth 10% ofthe transaction amount from participating merchandise outlets. In oneembodiment, the customer adds a pre-defined preference to customerpayment preferences store 106 setting goals of accumulating apredetermined number of points, amount of cash back, etc. In this case,the payment mode that results in the maximum gain towards one of thegoals is selected.

According to another embodiment, the proxy card serves as a proxy forinitiating a new payment mode, such as a new credit card, debit card,bank account, pre-paid gift card, health savings account, loyaltyrewards account, redemption coupon, etc. The customer selects and/orconfigures the new payment mode either manually via out-of-bandcommunication with proxy-card payment gateway 102, or automaticallyaccording to a pre-defined business rule, a customer preference, etc.,stored in customer payment preferences store 106. By enabling the proxycard to serve as a proxy for initiating a new payment mode, the newpayment mode can be used by customers at a POS via the proxy card,without the need to extensively modify hardware and/or software of thePOS to be compatible with the new payment mode. This decreasestime-to-market for implementing new payment modes on POS systems.

In yet another embodiment, a customer uses a temporary card as a proxycard for a misplaced or stolen credit card. For example, the customerreports the misplacement of the credit card to the corresponding issuer.The issuer deactivates the misplaced credit card. The customer purchasesa gift card at a local merchant and informs the issuer, via telephone, awebsite of the issuer, or any other suitable communication means, thatthe customer has purchased the gift card and wishes to use it as atemporary proxy for the misplaced credit card. In some embodiments, thegift card is issued by the same issuer of the misplaced credit card. Theissuer verifies the customer's information and configures the gift cardto be a temporary proxy for the misplaced credit card. The customer usesthe gift card as a temporary proxy to the misplaced credit card untilthe customer receives a replacement credit card from the issuer. In someembodiments, the proxy gift card's use is subject to a predeterminedtime period, a predetermined number of transactions, a predeterminedamount of credit, etc. Upon receiving the replacement credit card, thecustomer activates it and the proxy gift card becomes deactivated. Rapidcard fulfillment is achieved by enabling the customer to use a temporarycard that is readily accessible as a proxy to a misplaced card.

In another aspect, as an alternative to using a gift card as a proxy, acustomer uses another credit card as a proxy to a lost credit card. Insome embodiments the proxy is another credit card that was issued to thecustomer by the same issuer of the misplaced credit card. In addition,the customer can use a single credit card as a proxy to multiple lostcredit cards, or multiple credit cards as proxies to a single lostcredit card.

The proxy-card payment gateway 102 also can suggest a preferred paymentmode to the customer based at least in part on “past behavior” of thecustomer and/or majority of other customers who generated similarauthorization requests. For example, the proxy-card payment gateway cansuggest payment mode “C” for goods/services purchased in a restaurantbased on the recorded past behavior of the customer and/or majority ofother customers.

FIGS. 6A and 6B show a flowchart illustrating one example process 600for processing of payments for proxy cards, according to anotherembodiment of the present invention. Preferably, the process 600 may beexecuted in environment 100 described above in connection with FIG. 1.

The process begins at step S602, at which the proxy-card payment gateway102 receives a request for authorization of a payment. In one exampleembodiment of the present invention, the authorization request isinitiated via the merchant server 104 by the swiping of the proxy cardof the customer at the POS 112.

At step S604, since the request is initiated by the proxy card, theproxy-card payment gateway 102 determines the one or more payment modeoptions associated with the proxy card of the customer.

At step S606, in order to select at least one payment mode, theproxy-card payment gateway 102 looks up the customer payment preferencesstore 106 to identify if the customer has configured any pre-definedpreferences for the authorization request. For example, the customer mayhave specified a particular card, such as a loyalty gas card, for alltransactions related to payment for gas purchases. In another example,the customer might have provided a preference to exhaust the balance ina pre-paid gift card for any purchase below a certain amount. If thereare pre-defined preferences associated with the payment mode for theauthorization request, then at step S608, the proxy-card payment gateway102 further processes the authorization request. However, if there areno pre-defined preferences associated, then at step 610 the proxy-cardpayment gateway 102, adopts an alternative way for selecting at leastone payment mode.

At step S612, the proxy-card payment gateway 102 communicates the one ormore payment mode options to the customer, seeking authorization fromthe customer to select at least one payment mode. In an embodiment ofthe present invention, the proxy-card payment gateway 102 uses anout-of-band communication to inform the customer about one or morepayment mode options.

At step S614, the proxy-card payment gateway 102 receives at least oneselected payment mode from the customer as per their preferences.

Since the proxy-card payment gateway 102 selected at least one paymentmode from either step S606 or step S614, the proxy-card payment gateway102 sends request to the respective payment gateways 108 a-c, which haveissued the selected payment modes, to perform their respectiveauthorization checks. In an embodiment of the present invention, theprovider associated with proxy-card payment gateway 102 may itself haveissued one or more selected payment modes. Subsequently, at step S616the proxy-card payment gateway 102, and other payment gateways 108 a-cperform a corresponding authorization check on the selected cards issuedby them. Each authorization check is based at least in part on one ormore authorization criteria, which includes, but may not be limited to,checking credit limit of the selected payment mode, checking expiry dateof the payment mode, checking validity of the payment mode, checking anyother customer preferences that may be associated with the payment modesor alike.

At step S618, the proxy-card payment gateway 102 checks if the selectedpayment mode has been authorized. If the selected payment mode has beenauthorized, then at step S620, the proxy-card payment gateway 102proceeds to process the request for authorization of the payment.However, if the selected payment modes are not authorized, then at stepS622, the proxy-card payment gateway 102 proceeds to select at least onealternative payment mode.

At step S624, the proxy-card payment gateway 102 checks if any otherpayment mode options are left. If other payment mode options are left,then at step S626, the proxy-card payment gateway 102 proceeds to selectat least one alternative payment mode for the payment. To select analternative payment mode, the proxy-card payment gateway 102 moves backto step S606. However, in case no other payment mode options are left,then the proxy-card payment gateway 102 declines the authorizationrequest for the payment and at step S628, the proxy-card payment gateway102 sends a decline message to the POS 112 via the merchant server 104.In one embodiment, the decline message is presented to the customer viathe POS 112.

However, in case the selected payment mode gets authorized, then theproxy-card payment gateway 102 sends request to the respective paymentgateways 108 a-c, which have issued the selected payment modes, toauthorize the payment. In an embodiment of the present invention, theproxy-card payment gateway 102 may itself has issued one or moreselected payment modes. Subsequently, at step S630, the proxy-cardpayment gateway 102 and other payment gateways 108 a-c authorize thepayment from the selected payment modes issued by them.

At step S632, on completion of the payment, the proxy-card paymentgateway 102 sends an authorization code to the POS 112 via the merchantserver 104. In one embodiment, an authorization message is presented tothe customer via the POS 112.

IV. Example Implementations

The present invention (i.e., system 100, system 200, process 300,process 600, or any part(s) or function(s) thereof) may be implementedusing hardware, software or a combination thereof, and may beimplemented in one or more computer systems or other processing systems.However, the manipulations performed by the present invention were oftenreferred to in terms, such as comparing or checking, which are commonlyassociated with mental operations performed by a human operator. No suchcapability of a human operator is necessary, or desirable in most cases,in any of the operations described herein, which form a part of thepresent invention. Rather, the operations are machine operations. Usefulmachines for performing the operations in the present invention mayinclude general-purpose digital computers or similar devices.

In fact, in accordance with an embodiment of the present invention, thepresent invention is directed towards one or more computer systemscapable of carrying out the functionality described herein. An exampleof the computer systems includes a computer system 700, which is shownin FIG. 7.

The computer system 700 includes at least one processor, such as aprocessor 702. Processor 702 is connected to a communicationinfrastructure 704, for example, a communications bus, a cross over bar,a network, and the like. Various software embodiments are described interms of this exemplary computer system 700. After reading thisdescription, it will become apparent to a person skilled in the relevantart(s) how to implement the present invention using other computersystems and/or architectures.

The computer system 700 includes a display interface 706 that forwardsgraphics, text, and other data from the communication infrastructure 704(or from a frame buffer which is not shown in FIG. 7) for display on adisplay unit 708.

The computer system 700 further includes a main memory 710, such asrandom access memory (RAM), and may also include a secondary memory 712.The secondary memory 712 may further include, for example, a hard diskdrive 714 and/or a removable storage drive 716, representing a floppydisk drive, a magnetic tape drive, an optical disk drive, etc. Theremovable storage drive 716 reads from and/or writes to a removablestorage unit 718 in a well known manner. The removable storage unit 718may represent a floppy disk, magnetic tape or an optical disk, and maybe read by and written on by the removable storage drive 716. As will beappreciated, the removable storage unit 718 includes a computer usablestorage medium having stored therein, computer software and/or data.

In accordance with various embodiments of the present invention, thesecondary memory 712 may include other similar devices for allowingcomputer programs or other instructions to be loaded into the computersystem 700. Such devices may include, for example, a removable storageunit 720, and an interface 722. Examples of such devices may include aprogram cartridge and cartridge interface (such as that found in videogame devices), a removable memory chip (such as an erasable programmableread only memory (EPROM), or programmable read only memory (PROM)) andassociated socket, and other removable storage units 720 and interfaces722, which allow software and data to be transferred from the removablestorage unit 720 to the computer system 700.

The computer system 700 may further include a communication interface724. The communication interface 724 allows software and data to betransferred between the computer system 700 and external devices.Examples of the communication interface 724 include, but may not belimited to a modem, a network interface (such as an Ethernet card), acommunications port, a Personal Computer Memory Card InternationalAssociation (PCMCIA) slot and card, and the like. Software and datatransferred via the communication interface 724 are in the form of aplurality of signals, hereinafter referred to as signals 726, which maybe electronic, electromagnetic, optical or other signals capable ofbeing received by the communication interface 724. The signals 726 areprovided to the communication interface 724 via a communication path(e.g., channel) 728. The communication path 728 carries the signals 726and may be implemented using wire or cable, fiber optics, a telephoneline, a cellular link, a radio frequency (RF) link and othercommunication channels.

In this document, the terms “computer program medium” and “computerusable medium” are used to generally refer to media such as theremovable storage drive 716, a hard disk installed in hard disk drive714, the signals 726, and the like. These computer program productsprovide software to the computer system 700. The present invention isdirected to such computer program products.

Computer programs (also referred to as computer control logic) arestored in the main memory 710 and/or the secondary memory 712. Computerprograms may also be received via the communication interface 704. Suchcomputer programs, when executed, enable the computer system 700 toperform the features of the present invention, as discussed herein. Inparticular, the computer programs, when executed, enable the processor702 to perform the features of the present invention. Accordingly, suchcomputer programs represent controllers of the computer system 700.

In accordance with an embodiment of the present invention, where thepresent invention is implemented using a software, the software may bestored in a computer program product and loaded into the computer system700 using the removable storage drive 716, the hard disk drive 714 orthe communication interface 724. The control logic (software), whenexecuted by the processor 702, causes the processor 702 to perform thefunctions of the present invention as described herein.

In another embodiment, the present invention is implemented primarily inhardware using, for example, hardware components such as applicationspecific integrated circuits (ASIC). Implementation of the hardwarestate machine so as to perform the functions described herein will beapparent to persons skilled in the relevant art(s).

In yet another embodiment, the present invention is implemented using acombination of both the hardware and the software.

V. Conclusion

The various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample, and not limitation. It will be apparent to persons skilled inthe relevant art(s) that various changes in form and detail can be madetherein without departing from the spirit and scope of the presentinvention. Thus, the present invention should not be limited by any ofthe above described exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents.

In addition, it should be understood that the figures illustrated in theattachments, which highlight the functionality and advantages of thepresent invention, are presented for example purposes only. Thearchitecture of the present invention is sufficiently flexible andconfigurable, such that it may be utilized (and navigated) in ways otherthan that shown in the accompanying figures.

Further, the purpose of the foregoing Abstract is to enable the U.S.Patent and Trademark Office and the public generally, and especially thescientists, engineers and practitioners in the art who are not familiarwith patent or legal terms or phraseology, to determine quickly from acursory inspection the nature and essence of the technical disclosure ofthe application. The Abstract is not intended to be limiting as to thescope of the present invention in any way.

1-19. (canceled)
 20. A method comprising: storing, by a computer system,transaction information relating to a plurality of customers, includingpayment preference information for various ones of the plurality ofcustomers; receiving, by the computer system, a proxy transactionaccount number associated with a request for a transaction by aparticular one of the plurality of customers, wherein the proxytransaction account number is usable to select one of a plurality oftransaction accounts associated with the particular customer; selecting,by the computer system, a particular transaction account from theplurality of transaction accounts, wherein the selecting includes:responsive to determining that no applicable payment preferenceinformation of the particular customer is usable to select one of theplurality of transaction accounts, using stored transaction informationrelating to other ones of the plurality of customers to select theparticular transaction account; and authorizing, by the computer system,the request for the transaction using the particular transactionaccount.
 21. The method of claim 20, wherein the stored transactioninformation used to select the particular transaction account comprisespayment preference information for one or more other ones of theplurality of customers.
 22. The method of claim 21, wherein the paymentpreference information for the one or more other ones of the pluralityof customers is payment preference information for other customershaving characteristics similar to the particular customer.
 23. Themethod of claim 20, wherein the stored transaction information used toselect the particular transaction account comprises historicaltransaction data for one or more other ones of the plurality ofcustomers.
 24. The method of claim 23, wherein the historicaltransaction data for the one or more other ones of the plurality ofcustomers is historical transaction data that relates to transactionshaving similar characteristics to the transaction by the particularcustomer.
 25. The method of claim 24, wherein the similarcharacteristics indicate a similar type of merchant is associated withthe transaction by the particular customer.
 26. The method of claim 20,wherein the determining that no applicable payment preferenceinformation of the particular customer is usable to select one of theplurality of transaction accounts is based on a lack of stored paymentpreference information for the particular customer.
 27. The method ofclaim 20, wherein the determining that no applicable payment preferenceinformation of the particular customer is usable to select one of theplurality of transaction accounts is based on stored payment preferenceinformation for the particular customer not applying to the transactionby the particular customer.
 28. The method of claim 27, wherein thestored payment preference information for the particular customeridentifies an indicated one of the plurality of transaction accountsbased on an applicable one of a plurality of categories of a potentialtransaction by the particular customer, and wherein the transaction bythe particular customer does not apply to any of the plurality ofcategories.
 29. A system comprising: a processor; and a memory coupledto the processor, wherein the memory has stored thereon instructionsexecutable by the system to cause the system to perform operationscomprising: storing transaction information relating to a plurality ofcustomers, including payment preference information for various ones ofthe plurality of customers; receiving a proxy transaction account numberassociated with a request for a transaction by a particular one of theplurality of customers, wherein the proxy transaction account number isusable to select one of a plurality of transaction accounts associatedwith the particular customer; selecting a particular transaction accountfrom the plurality of transaction accounts, wherein the selectingincludes: responsive to determining that no applicable paymentpreference information of the particular customer is usable to selectone of the plurality of transaction accounts, using stored transactioninformation relating to other ones of the plurality of customers toselect the particular transaction account; and authorizing the requestfor the transaction using the particular transaction account.
 30. Thesystem of claim 29, wherein the stored transaction information used toselect the particular transaction account comprises payment preferenceinformation for one or more other ones of the plurality of customers.31. The system of claim 29, wherein the stored transaction informationused to select the particular transaction account comprises historicaltransaction data for one or more other ones of the plurality ofcustomers.
 32. The system of claim 29, wherein the determining that noapplicable payment preference information of the particular customer isusable to select one of the plurality of transaction accounts is basedon a previously selected transaction account failing an authorizationcheck.
 33. The system of claim 29, wherein the selecting furtherincludes communicating to the particular customer an indication of theparticular transaction account and receiving, from the particularcustomer, an indication that the particular customer has selected to usethe particular transaction account to conduct the transaction.
 34. Anon-transitory computer-readable medium having stored thereoninstructions executable by a computer system to cause the computersystem to perform operations comprising: storing transaction informationrelating to a plurality of customers, including payment preferenceinformation for various ones of the plurality of customers; receiving aproxy transaction account number associated with a request for atransaction by a particular one of the plurality of customers, whereinthe proxy transaction account number is usable to select one of aplurality of transaction accounts associated with the particularcustomer; selecting a particular transaction account from the pluralityof transaction accounts, wherein the selecting includes: responsive todetermining that no applicable payment preference information of theparticular customer is usable to select one of the plurality oftransaction accounts, using stored transaction information relating toother ones of the plurality of customers to select the particulartransaction account; and performing an authorization check for thetransaction using the particular transaction account.
 35. Thenon-transitory computer-readable medium of claim 34, wherein the storedtransaction information used to select the particular transactionaccount comprises payment preference information for one or more otherones of the plurality of customers.
 36. The non-transitorycomputer-readable medium of claim 35, wherein the payment preferenceinformation for the one or more other ones of the plurality of customersis payment preference information for other customers havingcharacteristics similar to the particular customer.
 37. Thenon-transitory computer-readable medium of claim 34, wherein theoperations further comprise: responsive to authorizing the transactionusing the particular transaction account, storing payment preferenceinformation of the particular customer based on the transaction.
 38. Thenon-transitory computer-readable medium of claim 37, wherein the paymentpreference information of the particular customer indicates a preferenceto conduct future transactions that are similar to the transaction usingthe particular transaction account.
 39. The non-transitorycomputer-readable medium of claim 34, wherein the operations furthercomprise: responsive to receiving an indication that the transaction isnot authorized using the particular transaction account, using thestored transaction information relating to other ones of the pluralityof customers to select an alternate transaction account from theplurality of transaction accounts.